fix(github): bind /builder to the plan the approver selected - #259

I think there is still an atomicity window in ensureArchitectPlanAcceptance worth closing before merge.

Right now supersedeOpenGithubPlanAcceptances(...) runs before the new plan_acceptance proposal is inserted. That creates two failure/race cases:

1. If the subsequent proposal/event insert fails, the previous valid open proposal has already been cancelled, leaving the issue with no live plan.
2. Two Architect completions can both run the supersede query before either inserts its own proposal, then both insert successfully and leave two live proposals.

The new ambiguous /builder guard makes case 2 fail closed at approval time, which is good, but it means the "newer plan supersedes older plans" invariant itself is still not atomic.

Could the new proposal creation + open event + superseding of older proposals be done in one DB transaction, with the new proposal inserted first and the older rows cancelled in that same transaction? A regression test that forces the create step to fail (and asserts the previous proposal stays open) would also pin this down.

Thanks @ALVZ93 — you were right about the window.

supersedeOpenGithubPlanAcceptances now runs after the new plan_acceptance insert, in the same transaction, under an issue-scoped advisory lock (architect-plan-issue:<org>:<repo>:<issue>). Concurrent Architect completions serialize on that lock, so they can no longer both cancel siblings and then both insert.

The regression you asked for is in builder-plan-policy.integration.test.ts: creating the replacement proposal with an invalid action type fails, the transaction rolls back, and the previous live plan stays open. A second test covers the success path (insert first, then cancel older rows) so bare /builder binds to the kept proposal.

Rebased onto current main.